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(57) In a multicast capable IP network (102) imple- 
mented over an ATM network, each client terminal on a 
multimedia conference, for each media type it transmits, 
is assigned a multicast IP address and a port number 
(together known as a socket) on which to transmit pack- 
ets, wherein each assigned multicast IP address is 
unique and different than the multicast IP address as- 
signed to any other client for any media type. Each client 
terminal then selects, for each media type, which clients 
on the conference it wants to receive packets from. Only 
packets that are in fact requested by a client are routed 
over the multicast IP network to the requesting client. A 
single special purpose Multicast Address Resolution. 
System (MARS) server is associated with the confer- 
ence when the conference is established. Each client 
terminal uses that MARS server, whether on the same 
or different IP sub-networks, but on a common ATM net- 
work, for purposes of mapping the multicast IP address- 
es used in the conference into a set of unicast ATM end- 
point addresses used by the ATM-connected client ter- 
minals. Similarly, when a specific conference uses a 
Multicast Server, a single special purpose Multicast 
Server is used for all clients on the conference, whether 
on the same or different IP sub-networks, for purposes 
of establishing point-to-multipoint ATM connections to 
the conference endpoints. 




Printed by Jouve. 75001 PARIS (FR) 



1 



EP 0 888 029 A2 



2 



Description 

invention relates to data communications, and more 
particularly, to the real-time interactive distribution of 
multimedia information using the multicast Internet Pro- 
tocol (IP) which is implemented over an ATM network. 

Background of the Invention 

Multimedia conferencing systems are typically 
characterized by the following: a directory service which 
lists the set of conferences; a dynamic mechanism for 
keeping track of the members of a conference as they 
join or leave the conference; tools for generating and 
processing the audio, video and data sharing compo- 
nents of a conference; a data network for interconnect- 
ing the members of a conference; and transport mech- 
anisms for distributing the multimedia conference con- 
tent among the conference members. 

Different transport mechanisms can be used to in- 
terconnect participants depending on the underlying ca- 
pabilities of the data network. Two basic communication 
capabilities are: unicast communication, meaning a 
point-to-point communication between a source and a 
destination endpoint; and multicast communication, 
meaning that one source endpoint reaches multiple des- 
tination endpoints. Since conferencing inherently im- 
plies the possibility of more than one destination end- 
point, if the network is capable only of unicast commu- 
nication, then eitherthe source must create multiple uni- 
cast connections, or Multicast Servers external to the 
network must be employed. In the former case, each 
sender of information sets up multiple connections to 
every receiver, and replicates the data on each connec- 
tion. Each receiver has multiple incoming connections, 
one for every sender of information. This approach be- 
comes inefficient as the number of participants (N) gets 
large for two reasons. Firstly, the number of network 
connections is proportional to the square of N. Secondly, 
each endpoint needs to replicate the data N times, pos- 
sibly leading to both an excessive and unnecessary use 
of bandwidth in the network and an excessive amount 
of computation at the source. If external Multicast Serv- 
ers are employed, then these servers perform the data 
replication function. Each sender of information needs 
to have a single unicast connection to the Multicast 
Server. Each receiver is connected to the Multicast 
Server. The number of connections is proportional to N, 
as all senders share the same set of connections to the 
set of receivers. The disadvantage of this scheme is that 
the Multicast Server becomes a bottleneck when N gets 
large. 

When the interconnection network is multicast ca- 
pable, more efficient alternatives are possible. With mul- 
ticast service, the source of the information sends the 
data only once - the replication is handled by the net- 
work. It is as if the Multicast Servers described in the 
previous paragraph are bundled into the network. Effi- 



cient techniques for replication may exist in the network. 
For example, the data replication can be performed in 
hardware, and the replication function can be distributed 
over the switches or routers of the network. Furthermore 
5 the replication topology may be very efficient, e.g. a 
spanning tree, where receivers are leafs of the tree, and 
the data source is the root of the tree. Note that it is also 
possible to use external Multicast Servers in conjunction 
with a multicast network. For example, the Multicast 
io Server may be connected to the receivers by multicast 
mechanisms, and to the sources by unicast mecha- 
nisms. 

The Internet Protocol (IP) is a widely used transport/ 
networking protocol. In the IP Application Programming 
Interface (API) (known as IP sockets or WINSOCK), ap- 
plication programs may write data to, or read data from 
a so-called socket just as if the socket was a "file de- 
scriptor" on the local computer. A socket is linked to a 
pair of numbers, i.e. an IP address and a positive integer 
referred to as a port number. For sending, the IP address 
used is the destination address to be placed in the des- 
tination field IP packet header, and the port number to 
be used by the application process on a remote machine 
for receiving the data. For receiving, the IP address is 
implicitly the local machine address (or in the case of IP 
multicast, the multicast group address of interest) , and 
the port number to be used by the application process 
on the local machine for receiving the data. 

Multicast IP, the primary mechanism by which IP 
networks support multicast, is an emerging capability of 
the IP protocol. In IP multicast service, unlike the unicast 
IP service where the address represents a specific and 
unique end-system, a sender transmits data addressed 
to an abstraction called a multicast address group. In 
the prior art, for a given conference, each media-type 
(e.g., audio, video) is associated with a particular port 
number and multicast IP address. All receivers for the 
given media-type listen to the specific socket consisting 
of the known multicast IP address and port number. All 
senders for the given media-type send to the specified 
socket consisting of the same multicast IP address and 
port number. Among different media-types, a different 
socket is utilized to enable different application pro- 
grams to handle the different media of the conference. 
In prior art systems, the multicast IP address may be the 
same or different among media types, but the port 
number is almost always different. 

Receivers find out about the existence of multicast 
groups and port numbers through various (centralized 
or distributed) directory mechanisms. For example, a 
well-known multicast IP address may be reserved for 
directory announcements. Alternatively, a centralized 
server may contain a list of multicast groups and distrib- 
ute this list to client terminals upon request. Once the 
appropriate multicast IP address information has been 
obtained from the directory mechanism, receivers send 
messages to Multicast Server processes (e.g., in multi- 
cast routers) indicating that they want to join a particular 
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group. The routers then exchange information about the 
set of users that want to communicate, and build up in- 
terconnection trees among themselves. Note that in the 
prior art, for a given media type, since a common mul- 
ticast IP address is used by all senders and receivers in 
a conference, and since the multicast IP address is the 
atomic unit of routing, this implies that the transmissions 
of all senders get routed to all receivers, even if each 
receiver is interested in a (possibly different) subset of 
the senders. This requires the receiver's application pro- 
gram to receive, process, and discard unwanted infor- 
mation; furthermore the typically expensive network 
bandwidth required to transport the unwanted informa- 
tion is wasted. 

Receivers communicate with multicast routers over 
some sub-network technology to which both are at- 
tached, such as, for example, Ethernet, Frame Relay, 
or ATM. When IP multicast is supported over a sub-net- 
work that has a native multicast ability with a similar 
service capability to that of IP (e.g., Ethernet), multicast 
IP addresses may be mapped directly onto Ethernet ad- 
dresses. Each terminal on the Ethernet then listens for 
those multicast Ethernet addresses that it is interested 
in, and ignores the rest. 

When IP multicast is supported over a virtual circuit 
oriented sub-network, such as ATM, that does not have 
a native multicast capability similar to IP, it is necessary 
to have an address resolution mechanism to map a mul- 
ticast IP address into a set of unicast ATM addresses. 
In the prior art, a Multicast Address Resolution System 
(MARS) server is utilized for this purpose. When IP re- 
ceivers want to join an IP multicast group, they send a 
message to the MARS server. The MARS server then 
informs all senders to the IP multicast group of the iden- 
tity of the new receivers. In the prior art, however, a 
MARS server is only associated with a static set of IP 
endpoints that are specific to a single sub-network. 
Thus, if a receiver is a member of a local sub-network, 
the MARS server specific to that sub-network is used. 
If conference members are on different sub-networks, 
one approach of the prior art is to forward multicast IP 
packets via IP multicast routers connecting the different 
sub-networks. With respect to the sub-network of which 
a sender is a member, the multicast router is treated as 
another receiver by the MARS server of the sender's 
sub-network. With respect to the sub-networks in which 
a receiver is a member, the multicast router is treated 
as a sender by the MARS server of the receiving sub- 
network. Each sub-network thus requires a separate 
MARS server and there are no interactions between the 
plural MARS servers. If it can be assumed that the send- 
ers and receivers are attached to a common ATM net- 
work, the prior art imposes an extra layer of protocol 
processing and packet forwarding that introduces addi- 
tional delays and unnecessary bandwidth utilization. 
One way of avoiding the use of multicast routers in this 
context is to allow the MARS servers in the different sub- 
networks to communicate directly with one another in 



4 

identifying the ATM addresses of senders and receivers 
in the different sub-networks. Such mu Itiple MARS serv- 
ers thus need to communicate with each other for con- 
trol and coordination purposes, which also requires sig- 
5 nificant overhead and signaling there between, and the 
establishment of an inter-server protocol. 

Summary of the Invention 

10 In accordance with the present invention rather than 
using the fixed plural MARS servers associated with 
each individual IP sub-network, a single special purpose 
MARS server is associated with a particular conference 
at the time the conference is established. All participants 
of a particular conference, whether on the same or dif- 
ferent IP sub-networks, but on a common ATM network, 
use this same special purpose MARS server for that 
conference. Thus, the need for communication among 
either the set of plural MARS servers or multicast routers 
is eliminated. 

When a conference is established, a Directory 
Server allocates from the then available and unused 
multicast IP addresses, a set of such addresses to be 
used for the conference based on the maximum number 
of expected participants, which number is provided by 
a conference originator. As each participant joins the 
conference, the participant's client terminal is assigned 
a port number and multicast IP address on which to 
transmit for each media type, wherein the multicast IP 
address is from the set of multicast IP addresses allo- 
cated for use by that conference. In this manner, by 
choosing to receive on only selected multimedia ad- 
dresses and port numbers, each client terminal receives 
transmissions for each media type from only those client 
terminals it desires. 

As it joins the conference, each client is also pro- 
vided with the ATM address of the single special pur- 
pose MARS server assigned for use for that specific 
conference when the conference was originated. Each 
client then configures its IP-over-ATM interface to use 
that specific MARS server for the mapping of the con- 
ference multicast IP addresses to ATM addresses. Fur- 
ther, if the specific conference also uses a Multicast 
Server (MCS), the ATM address of a single special pur- 
pose MCS used for the conference is also provided to 
each client as it joins the conference. 

Brief Description of the Drawings 

FIG. 1 is a block diagram showing a plurality of client 
terminals connected to a multicast capable IP net- 
work over a common ATM network, to which is also 
connected a Directory Server for establishing a con- 
ference, and a single special purpose MARS server 
and single special purpose Multicast Server in ac- 
cordance with the present invention; 
FIG. 2 is a chart illustrating the steps associated 
with establishing a conference by a conference 
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originator on the network of FIG. 1 ; 
FIG. 3 is a chart illustrating the steps associated 
with a user joining an already established confer- 
ence on the network of FIG. 1; 
FIG. 4 is a chart illustrating the interactive steps be- 
tween a client terminal and a single special purpose 
MARS server when the client terminal joins an ex- 
isting conference; and 

FIG. 5 is a chart illustrating the interactive steps be- 
tween a client terminal and the special purpose 
MARS server and a special purpose Multicast Serv- 
er, when a Multicast Server is also employed in the 
conference. 

Detailed Description 

With reference to FIG. 1, multimedia client terminals 
101-1 - 101-5 are connected to a multicast capable In- 
ternet Protocol (IP) data network 102 implemented over 
a common ATM network comprising ATM switches 1 03, 
104 and 105, and ATM interconnections 120, 121, and 
122. Each of the client terminals 101-1 - 101-5 is con- 
nected to the IP network 1 02 over ATM. Each client ter- 
minal 101-1 - 101-5 has a unique ATM unicast endpoint 
address. Network 102 comprises plural IP sub-networks 
110, 111, and 112. Thus, as illustrated in FIG. 1, client 
terminals 101 -1 and 101-2 are members of common IP 
sub-network 110 clients terminals 101 -3 and 101-4 are 
member of I P sub-network 111, and client terminal 1 01 -5 
is a member of IP sub-network 112. IP sub-networks 
110, 111 and 112 are interconnected through multicast 
capable IP routers 11 3 and 114. A Directory Server (DS) 
106, which need not operate in a multicast fashion, is 
connected to the IP network through router 107, which 
need not be multicast capable. 

A single special purpose MARS server 126 is also 
connected to network 102 through ATM switch 103. The 
function of this MARS server is, for a particular confer- 
ence, to maintain the mapping of the particular multicast 
IP addresses used by that specific conference to the 
possibly changing set of ATM unicast addresses of the 
conference client terminals. 

Directory Server 106 functions to maintain a list of 
multicast IP addresses and ports available for use for a 
plurality of different and possibly concurrent conferenc- 
es, to assign a subset of those addresses and ports to 
a particular conference when a conference is initiated, 
and to assign from that subset a unique multicast IP ad- 
dress and port number to each media type of each client 
as that client makes a request to become a member of 
that conference. Once each socket (multicast IP ad- 
dress and port number) is assigned to a particular client 
for each media type for use during a conference, the 
assigned multicast IP addresses are marked as being 
unavailable and cannot be assigned to any other client 
attempting to join that same conference. Once a partic- 
ipant departs a still ongoing conference, the multicast 
IP addresses assigned to that participant's client are 



marked as being available and can be assigned to the 
client of a later joining participant. Directory Server 106 
also assigns the ATM address of the special purpose 
MARS server 1 26 to be used by the ATM client terminals 
5 on the conference. 

Upon receiving the set of sockets assigned to it for 
the conference, the client may decide how it wants to 
interact in the conference. Specifically, for each media 
type the client may only want to only receive, or to both 
io receive and transmit, or to just transmit. Further, the cli- 
ent may choose to receive a particular media type from 
only select other clients on the conference. When a con- 
ference is established and a client joins an established 
conference, therefore, it receives a list of sockets used 
for transmitting by the other clients associated with the 
conference. At any time during the conference, it may 
then receive packets from the other clients in the con- 
ference on the sockets assigned for transmission to 
those other clients, or it may choose not to receive pack- 
ets of any or all media types from other clients by either 
not adding the other client's socket(s) to its Multicast Re- 
ceive Address List (MRAL), or by deleting the other cli- 
ent's socket from its MRAL if it was previously receiving 
transmissions from the other client. The client then sets 
its local interface to receive only those packets whose 
multicast IP addresses/port numbers match the ones in 
its MRAL. Also, upon receiving the ATM address of the 
special purpose MARS server 126 assigned to the con- 
ference, each client sets up a virtual circuit to this MARS 
server. During the conference, each client will access 
this MARS server at its ATM address to map the multi- 
cast IP addresses used in the conference to the appro- 
priate set of ATM endpoint addresses. 

In FIG. 1, for example, the conference may com- 
prise the client terminals 101-1 - 101-5. Once the con- 
ference is established by the conference originator on 
Directory Server 1 06, each client terminal is able to con- 
nect to each other client terminal through a combination 
of queries to MARS server 126, and the setting up of 
point-to-multipoint virtual circuits via ATM signaling. For 
example, if client terminals 101-4 and 101-5 each wants 
to receive the video transmitted by client terminal 101-1, 
client terminals 101-4 and 101-5 register their ATM uni- 
cast addresses with MARS server 126, which then as- 
sociates those ATM unicast addresses with the multi- 
cast IP address that client terminal 101-1 uses for video 
transmission. When client terminal 101-1 transmits, 
therefore, it sends the multicast IP address on which it 
transmits its video to MARS server 126 and receives 
therefrom the list of ATM unicast addresses to which 
ATM connections should be established. Client terminal 
101-1 then sets up a point-to-multipoint virtual circuit to 
the ATM addresses of client terminals 101 -4 and 101-5. 
If, during an ongoing conference, client terminal 101-3 
decides it also wants to receive the video signal being 
transmitted by client terminal 101-1, it sends a message 
to MARS server 1 26 indicating that it wants to join the 
multicast group (i.e., receive transmissions destined to 
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the particular multicast IP address to which client termi- 
nal 101-1 is transmitting). MARS server 126 then adds 
the ATM address of client terminal 101-3 to the list of 
ATM addresses associated with that multicast IP ad- 
dress on which client terminal 101-1 transmits its video 
signal. Further, MARS server 126 sends an indication 
to client terminal 101-1 to add client terminal 101-3 to 
the previously established point-to-multipoint ATM vir- 
tual circuit. If, during a conference, one of the clients 
already receiving the video transmissions from client 
terminal 101-1 (such as client terminal 101-4) decides 
that it no longer wishes to receive those transmissions, 
it then sends a message to MARS server 1 26 indicating 
that it wishes to leave the multicast group (i.e., no longer 
wants to receive transmissions destined to that particu- 
lar multicast IP address to which client terminal 101-1 is 
transmitting). MARS server 126 then sends an indica- 
tion to client terminal 101-1 to remove client 101 -4 from 
the previously established point-to-multipoint ATM vir- 
tual circuit. 

It has been assumed above that each transmitting 
client terminal sets up its own point-to-multipoint ATM 
virtual circuit for each media type to each client terminal 
that wants to receive that media type. The resulting large 
number of point -to-multipoint ATM virtual circuits could 
exhaust switch virtual channel identifier resources. Ac- 
cordingly, an ATM Multicast Server (MCS) is sometimes 
employed in a conference in order to share point-to- 
multipoint connections. Transmitters then set up a uni- 
cast point-to-point ATM virtual circuit to the MCS, which 
in turn establishes a point-to-multipoint ATM virtual cir- 
cuit to each client terminal desiring to receive transmis- 
sions. Thus, all transmitters ultimately share the Multi- 
cast Server's point-to-multipoint virtual circuit thereby 
reducing the demand on ATM switch virtual channel 
identifier resources. In the prior art multiple of such Mul- 
ticast Servers may be deployed such that each sub-net- 
work has its own Multicast Server. As previously de- 
scribed with respect to per-sub-network prior art MARS 
servers, inter-subnetwork communication between end- 
points in different sub-networks requires the use of mul- 
ticast routers. As before, if it can be assumed that the 
senders and receivers are attached to a common ATM 
network, the prior art use of multicast routers imposes 
an extra layer of protocol processing and packet for- 
warding that introduces additional delays and unneces- 
sary bandwidth utilization. In accordance with the 
present invention, if an MCS is used within the confer- 
ence, the Directory Server also provides each client with 
the ATM address of a single special purpose Multicast 
Server for use in that specific conference. Each client 
then configures its IP-over-ATM interface to use that 
specific special purpose MCS for all point-to-multipoint 
ATM communication. 

With reference again to FIG. 1, special purpose 
MCS 130 is shown connected to network 102 through 
ATM switch 103. For purposes of an example, it can 
again be assumed that the conference comprises client 
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terminals 101-1 - 101-5. If client terminals 101-4 and 
101-5 each wants to receive the video transmitted by 
client terminal 101-1, terminals 101-4 and 101-5 register 
their ATM unicast addresses with MARS server 126, 
5 which then associates those ATM unicast addresses 
with the multicast IP address that client terminal 101-1 
uses for transmission. When client terminal 101-1 is 
ready to transmit, it sets up an ATM virtual circuit to MCS 
130. When client terminal 101-1 transmits, it sends the 

io multicast IP address on which it transmits its video to 
MARS server 1 26. MARS server 1 26 then sends the list 
of ATM unicast addresses to which ATM connections 
need to be established to MCS 1 30. MCS 1 30 then sets 
up a point-to-multipoint virtual circuit to the ATM ad- 

15 dresses of clients 101-4 and 101-5. Client terminal 
101-1 then transmits to MCS 130 along the previously 
established ATM virtual circuit. When a client joins an 
on-going conference or leaves an ongoing conference, 
there is a similar interaction between MARS server 126 

20 and MCS 130. 

With reference to FIG. 2, the steps to originate a 
conference by an ATM connected conference originator 
are detailed. At step 201 , by sending a packetized mes- 
sage, a user contacts the Directory Server to create a 

25 conference. This could be accomplished by the user 
clicking on an icon on a browser running on the client, 
or by the user inputting a particular URL address. At step 
202, the Directory Server requests the authorization of 
the user as a conference originator. At step 203, the user 

30 provides his or her ID plus a password. At step 204, if 
recognized by the DS as an authorized conference orig- 
inator, the user is authenticated and permitted to pro- 
ceed to establish the conference. If not, the process 
ends at step 209. If authenticated, at step 205, the Di- 

35 rectory Server returns to the user, for example, an 
HTML-formatted page requesting information from the 
originator such as the name and description of the con- 
ference, the media types involved with the conference, 
the types of encoding used by each of the media types, 

40 the time at which the conference is scheduled to take 
place and its expected duration, the maximum number 
of participants, a list of valid participants, and the name 
and phone number of a contact point for the proposed 
conference. The user provides the requested informa- 

45 tion at step 206. At step 207, the Directory Server re- 
turns to the conference originator a password to be used 
by the participants in order to join the conference and 
allocates a set of multicast IP addresses and port num- 
bers from the space of available multicast IP addresses 

50 and port numbers for each media type. In addition, the 
ATM address of the particular single special purpose 
MARS server that will be used for this conference is re- 
turned. Further, if a single special purpose Multicast 
Server is to be used for this specific conference, the 

55 ATM address of this MCS is also returned by the Direc- 
tory Server. At step 208, the Directory Server marks the 
assigned multicast IP addresses as being unavailable 
for assignment to any other conference, and the asso- 



5 



9 



EP 0 888 029 A2 



10 



ciations of the specific conference with the addresses 
of the assigned MARS server and the MCS, if the latter 
is used. 

Once the conference originator has established the 
conference with the Directory Server, users at the client 
terminals may join the conference within its scheduled 
time. With reference to FIG. 3, at step 301, a potential 
ATM connected conferee contacts the DS by sending a 
packetized request either by clicking on an icon or in- 
putting the URL address of the DS on the client's brows- 
er. At step 302, the client receives from the DS a list of 
ongoing conferences from which the user selects the 
conference to which he or she then wants to join. At step 
303, in response to the selected conference, the DS 
sends a form back to the user's client requesting the us- 
er's ID and the password assigned by the DS to the con- 
ference. It is assumed that the password is made avail- 
able to the conferees by an external system, such as a 
phone call/message, or encrypted e-mail. The user in- 
puts the requested information and, at step 304, the DS 
compares the inputted information with its list of valid 
conference participants as inputted by the conference 
originator, and the password established for the confer- 
ence. If the user is not authenticated at step 305, he or 
she is precluded from joining the conference and the 
process ends at step 310. If authenticated at step 305, 
the DS provides at step 306, a multicast IP address and 
port number for each media type for the client terminal 
to transmit on and a list of sockets for each media type 
to receive on for the other client terminals which are par- 
ticipating in the conference and for which the user is a 
valid recipient. In addition, the DS provides the ATM ad- 
dress of the single special purpose MARS server as- 
signed to the conference and the single special purpose 
Multicast Server, if the latter is being used. At step 307, 
the user selects those clients from which to receive each 
media type from the list of sockets on which the other 
clients are transmitting. This is done by either adding 
each such other client's address to its MRAL or deleting 
such other client's address from its MRAL if it has been 
previously receiving a currently unwanted media type of 
transmission from that other client. When a client elects 
to exit a conference, it deletes all the addresses /ports 
associated with the conference from its MRAL. When 
the conference is concluded, the Directory Server, at 
step 309, marks the addresses and ports assigned to 
the conference as available so they can be assigned to 
another conference. 

FIG. 4 illustrates the interactive steps between a cli- 
ent terminal and the special purpose MARS server when 
the client terminal wants to join an existing conference 
for the case where a Multicast Server is not used for the 
conference. After the client terminal receives from the 
Directory Server the multicast IP addresses and port 
numbers on which to receive the other participants' 
transmissions for which it is a valid receiver, and the 
ATM address of the special purpose MARS server to be 
used for the conference (step 306 in FIG. 3), at step 401 , 



the client updates its local MARS table. The local MARS 
table enables the client to be simultaneously associated 
with plural conferences. For each conference, the set of 
associated multicast IP addresses is in turn associated 
5 with the ATM address of the MARS server used for that 
conference. At step 402, for each endpoint and media 
type from which it wants to receive transmissions on the 
existing conference that it is joining, the client issues a 
MARS-JOIN message indicating the multicast IP ad- 

10 dress/port number associated with that endpoint/media 
type. At step 403, the special purpose MARS server up- 
dates a local table containing the list of ATM endpoints 
that are members of each IP multicast group to include 
the requesting client. At step 404, the MARS server then 

*5 instructs the other transmitting members of the existing 
conference to add the new client for each media type 
requested by the client. Each of these other client ter- 
minals thus adds the new client as a leaf to its respective 
distribution tree. The new client, from that point on, can 

20 receive all transmissions associated with the mu itimedia 
conference which it has selected and for which it has 
been validated. At step 405, the MARS server adds the 
new client as a leaf of the control channel, which is the 
mechanism by which the MARS server sends messages 

25 to the members of the conference group. It is through 
this mechanism that the new client can receive subse- 
quent messages about the existence of new group 
members or the deletion of existing group members. 
FIG. 5 illustrates the interactive steps between a cli- 

30 ent terminal, the special purpose MARS server and the 
special purpose Multicast Server when the client termi- 
nal wants to join an existing conference for the case 
where a Multicast Server is used for the conference. In 
this case, there is little advantage to employing multiple 

35 multicast IP addresses for different senders. It can be 
assumed that for a given media type, a single multicast 
IP address is used by all senders. As in FIG. 4, the client 
receives from the Directory Server the multicast IP ad- 
dresses and port numbers on which to receive the other 

40 participants' transmissions for which it is a valid receiver, 
and the ATM address of the special purpose MARS 
server to be used for the conference, as well as, for this 
case, the ATM address of the particular Multicast Server 
to be used for this conference (from step 306 in FIG. 3). 

45 At step 501 , the client updates its local table listing the 
ATM addresses of the MARS servers and Multicast 
Servers corresponding to the sets of multicast IP ad- 
dresses for that conference. At step 502, for each media 
type from which it wants to receive transmissions, the 

so client issues a MARS-JOIN message indicating the mul- 
ticast IP address/port number associated with that me- 
dia type. At step 503, the MARS server updates a local 
table containing the list of ATM endpoints that are mem- 
bers of each IP multicast group. At step 504, the special 

55 purpose MARS server then instructs the special pur- 
pose Multicast Server to add the new client as a leaf of 
its distribution tree corresponding to the multicast ad- 
dresses of the conference. From this point on the new 
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addresses of each of the at least some of the plu- 
rality of clients receiving such transmitted packets. 

2. The method of claim 1 wherein the conference is a 
s multimedia conference in which packets of plural 

media types are transmitted by the at least one cli- 
ent on different multicast IP addresses and the spe- 
cial purpose MARS server manages mapping for 
each media type between the multicast IP address 
10 to which said at least one of said plurality of clients 
transmits packets of that media type and the unicast 
endpoint addresses of each of the at least some of 
the plurality of clients receiving transmitted packets 
of that media type. 

15 

3. The method of claim 2 wherein the plural media 
types are at least one of audio, video and/or data. 



client is able to receive all transmissions associated with 
the multimedia conference which is has selected and for 
which it has been validated. 

Advantageously, by linking a specific conference to 
a specific single special purpose MARS server, and, 
where employed, a singe special purpose Multicast 
Server, the scalability of the conferencing system is im- 
proved. Thus, as a new conference is created, an addi- 
tional MARS server or MCS can be added for the new 
conference. Further, by enabling the use of different 
MARS servers for different conferences, the possibility 
is eliminated that members of one conference may ac- 
cidentally get information pertaining to a different con- 
ference. 

• Although described above in the context of IP over 
ATM networks, the present invention can be applied to 
other switched virtual circuit technologies such as, for 
example, IP over ISDN, IP over X.25, and IP over Frame 
Relay. Further, the network need not have a native point - 
to-multipoint capability. In such a case, the point-to- 
multipoint connection would be via the Multicast Server 
and the connection from the Multicast Server to the end- 
points would consist of plural point-to-point connections. 
Also, the employment of a single special purpose MARS 
server dedicated to a specific set of IP multicast groups 
has applicability to any IP Multicast over ATM system, 
not just multimedia conferencing. Also, although de- 
scribed in connection with a system in which each client 
is assigned a different multicast IP address on which to 
transmit, the present invention does not require such ar- 
rangement and can be employed in a system which us- 
es a different algorithm for assigning sets of multicast 
addresses to a given conference. 

The above-described embodiment is illustrative of 
the principles of the present invention. Other embodi- 
ments could be devised by those skilled in the art without 
departing from the spirit and scope of the present inven- 
tion. 



Claims 



4. The method of claim 1 wherein the virtual circuit net- 
20 work is an ATM network, the clients are connected 

to the ATM network via ATM, and the endpoint ad- 
dresses are ATM addresses. 

5. The method of claim 2 wherein the special purpose 
25 MARS server maintains for each multicast IP ad- 
dress a set of the unicast endpoint addresses of 
those clients on the conference which are currently 
receiving transmissions on that multicast IP ad- 
dress 

30 

6. The method of claim 1 further comprising the step 
of assigning a single special purpose Multicast 
Server connected to the network for use for that 
conference for establishing point-to-multipoint con- 

35 nections to the clients at their unicast endpoint ad- 
dresses. 

7. The method of claim 2 further comprising the step 
of assigning to each client in the conference for 

40 each media type a different unique multicast IP ad- 
dress on which to transmit packets. 



1. In a multicast capable IP network comprising plural 
IP sub-networks implemented over a common 
switched virtual circuit in which during a conference 45 
at least one of a plurality of clients at an associated 
unicast endpoint address transmits packets for mul- 
ticast transmission to at least some of the plurality 
of clients in the conference at their respective uni- 
cast endpoint addresses using multicast IP ad- so 
dresses to transmit on and receive over, a method 
comprising: 

assigning a single special purpose Multicast 
Address Resolution System (MARS) server con- 
nected to the network for use for that conference for 55 
managing mapping between the multicast IP ad- 
dress to which said at least one of said plurality of 
clients transmits packets and the unicast endpoint 



8. The method of claim 7 wherein the multicast IP ad- 
dresses assigned to the clients in the conference 
are from a group of multicast I P addresses allocated 
to the conference. 

9. In a multicast capable I P network comprising plural 
IP sub-networks implemented over a common 
switched virtual circuit on which packets are trans- 
mitted by a plurality of clients on multicast IP ad- 
dresses for multicast transmission, a method for a 
client at a unicast endpoint address to join a con- 
ference and receive transmissions from at least one 
other client in the conference at another unicast 
endpoint address, the method comprising the steps 
of: 
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providing to the joining client an endpoint ad- 
dress of a single special purpose Multicast Ad- 
dress Resolution System (MARS) server as- 
signed for use for the conference, which MARS 
server maintains for each multicast IP address 5 
a set of all the unicast endpoint addresses of 
those clients on the conference which receive 
transmissions on that multicast IP address; 
receiving a request from the joining client to re- 
ceive transmissions from the at least one other io 
client; and 

adding, in the single special purpose MARS 
server, the unicast endpoint address of the join- 
ing client to a group of endpoint addresses as- 
sociated with the particular multicast IP ad- is 
dress on which the at least one other client 
transmits. 

10. The method of claim 9 further comprising the step 

of instructing the at least one other client to add the 20 
joining client as an additional endpoint on a point- 
to-multipoint virtual circuit to the group of endpoint 
addresses to which the at least one other client 
transmits on the particular multicast IP address. 

25 

11. The method of claim 9 wherein the conference is a 
multimedia conference in which packets of plural 
media types are transmitted by the at least one oth- 
er client on different multicast I P addresses, and the 
request from the joining client includes a request to 30 
receive transmissions from the at least one other 
client of packets of at least one of the plural media 
types. 

12. The method of claim 11 wherein the plural media 35 
types are at least one of audio, video and/or data. 

13. The method of claim 11 further comprising the step 
of assigning to the joining client, for each media type 

for which packets are transmitted, a multicast IP ad- 40 
dress on which to transmit such packets that is dif- 
ferent and unique from any multicast IP address as- 
signed to any other client on the conference. 

14. The method of claim 1 3 wherein the multicast IP ad- 45 
dresses assigned to the joining client are from a 
group of multicast IP addresses allocated to the 
conference. 

15. The method of claim 9 wherein the virtual circuit net- so 
work is an ATM network, the joining client and the 
other clients are connected to the ATM network via 
ATM, and the unicast endpoint addresses are ATM 
addresses. 

55 

16. The method of claim 9 further comprising the steps 
of: 



14 

providing to the joining client an endpoint ad- 
dress of a single special purpose Multicast 
Server assigned for use for the conference, 
which Multicast Server establishes point -to- 
multipoint connections to clients in the confer- 
ence; 

establishing a virtual connection between the 
joining client and the special purpose Multcast 
Server; 

providing the endpoint address of the joining 
client to the Multicast Server; and 
adding the endpoint address of the joining cli- 
ent to the Multicast Server's point-to-multipoint 
connections. 



8 




9 



EP 0 888 029 A2 



FIG. 2 

( START ) 



USER CONTACTS DS TO CREATE CONFERENCE 
BY SENDING PACKETIZED MESSAGE 

I 

DS REQUEST AUTHORIZATION OF USER 
AS CONFERENCE ORIGINATOR 



USER PROVIDES ID PLUS PASSWORD 



USER AUTHENTICATED ? 




YES 



DS RETURNS HTML- FORMATTED PAGE 
REQUESTING NAME AND DESCRIPTION OF CONFERENCE, 
MEDIA TYPES, TYPE OF ENCODING, TIME AND 
DURATION OF CONFERENCE, MAXIMUM NUMBER 
OF PARTICIPANTS, LIST OF VALID PARTICIPANTS 
AND CONTACT POINT 

USER PROVIDES REQUESTED INFORMATION 

♦ 

DS RETURNS A PASSWORD TO BE USED BY 
PARTICIPANTS TO JOIN CONFERENCE AND A SET 
OF MULTICAST IP ADDRESSES FROM SPACE OF 
UNUSED ADDRESSES AND PORT NUMBERS FOR EACH 
MEDIA TYPE AND THE ATM ADDRESSES OF MARS 
SERV ER TO BE USED AND MULTICAST SERVER(IF USED) 

\ 

DS MARKS ASSIGNED ADDRESSES AND PORTS 
UNAVAILABLE, AND THE ASSOCIATION OF 
CONFERENCE WITH ADDRESSES OF ASSIGNED MARS 
SERVER AND MULTICAST SERVER (IF USED ) 



QST) 
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FIG. 3 




( START ) 



POTENTIAL CONFEREE CONTACTS OS 
BY SENDING PACKETIZED REQUEST 



I 



USER RECEIVES LIST OF ONGOING CONFERENCES 
AND SELECTS CONFERENCE TO JOIN 



303 



304- 



I 



306- 



307- 



308- 



309- 



OS SENDS FORM BACK TO USER REQUESTING ID 
AND PASSWORD FOR SELECTED CON FERENCE 

r 



DS AUTHENTICATES USER AS A VALID 
PARTICIPANT FOR SELECTED CONFERENCE 



305- 



I 



XUSER AUTHENTICATED ^M- 



DS PROVIDES IP MULTICAST ADDRESSES AND PORT NUMBERS 
FOR USER'S CLIENT TERMINAL TO TRANSMIT ON AND LIST OF 
OF SOCKETS FOR EACH MEDIA TYPE FOR OTHER PARTICIPANTS 
IN THE CONFERENCE TO RECEIVE ON AND ATM ADDRESSES OF 
MARS SERVER TO USE AND MULTICAST SERVER (IF USED) 



USER SELECTS CLIENTS FROM WHICH TO RECEIVE 
EACH MEDIA TYPE FROM LIST OF SOCKETS ON WHICH 
OTHER CLIENTS ARE TRANSMITTING BY EITHER ADDING 
A CLIENTS ADDRESSES TO ITS MRAL OR DELETING ITS 
ADDRESSES FROM ITS MRAL, IF PREVIOUSLY RECEIVING 
FROM THAT CLIENT 



I 



USER AT CLIENT EXITS CONFERENCE AND CLIENT 
DELETES ALL ADDRESSES ASSOCIATED 
WITH CONFERENCE FROM MRAL 



I 



AT CONCLUSION OF CONFERENCE, DS MARKS ADDRESSES AND 
PORTS PREVIOUSLY ASSIGNED TO CONFERENCE AS UNUSED 



310 



"~ ( END ) 
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FIG. 4 



(FROM STEP 306 IN FIG.3) 



CLIENT UPDATES ITS LOCAL TABLE ASSOCIATING 
ATM ADDRESS OF MARS SERVER WITH MULTICAST 
IP ADDRESSES USED IN CONFERENCE 



CLIENT ISSUES MARS- JOIN REQUEST FOR 
DESIRED ENDPOINTS AND MEDIA TYPES 



MARS SERVER UPDATES LOCAL TABLE 
LISTING MEMBERS OF EACH GROUP 



MARS SERVER ISSUES ADD-NEW-CLIENT 
DIRECTIVE FOR ALL DESIRED 
ENDPOINTS /MEDIA TYPES 



MARS SERVER ADDS NEW CLIENT 
TO CONTROL CHANNEL 
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FIG. 5 



(FROM STEP 306 IN TOj) 



CLIENT UPDATES ITS LOCAL TABLE ASSOCIATING 
ATM ADDRESSES OF MARS SERVER AND MULTICAST 
SERVER WITH MULTICAST IP ADDRESSES 
USED IN CONFERENCE 



CLIENT ISSUES MARS- JOIN REQUEST FOR 
DESIRED ENDPOINTS AND MEDIA TYPES 



MARS SERVER UPDATES LOCAL TABLE 
LISTING MEMBERS OF EACH GROUP 



MARS SERVER ISSUES ADD-NEW-CLIENT DIRECTIVE 
TO MULTICAST SERVER 
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(57) In a multicast capable IP network (102) imple- 
mented over an ATM network, each client terminal on a 
multimedia conference, tor each media type it transmits, 
is assigned a multicast IP address and a port number 
(together known as a socket) on which to transmit pack- 
ets, wherein each assigned multicast IP address is 
unique and different than the multicast IP address as- 
signed to any other client for any media type. Each client 
terminal then selects, for each media type, which clients 
on the conference it wants to receive packets from. Only 
packets that are in fact requested by a client are routed 
over the multicast IP network to the requesting client. A 
single special purpose Multicast Address Resolution 
System (MARS) server is associated with the confer- 
ence when the conference is established. Each client 
terminal uses that MARS server, whether on the same 
or different I P sub-networks, but on a common ATM net- 
work, for purposes of mapping the multicast IP address- 
es used in the conference into a set of unicast ATM end- 
point addresses used by the ATM-connected client ter- 
minals. Similarly, when a specific conference uses a 
Multicast Server, a single special purpose Multicast 
Server is used for all clients on the conference, whether 



on the same or different IP sub-networks, for purposes 
of establishing point-to-multipoint ATM connections to 
the conference endpoints. 
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